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ABSTRACT 


This  thesis  introduces  the  usage  of  the  IDEF  (ICAM  [Integrated  Computer 
Manufacturing]  Definitions  Language)  methodology  to  model  process  redesign.  A 
research  team  was  assembled  at  the  Naval  Postgraduate  School  in  Monterey, 
California  to  attend  a  five-day  IDEF  conference  to  create  a  model  of  process 
redesign.  This  model  will  be  used  to  develop  a  handbook  for  functional  managers 
to  evaluate  and  redesign  their  own  business  processes. 
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I.  INTRODUCTION 


A.  BACKGROUND 

For  the  Corporate  Information  Management  (CIM)  initiative  to  be  considered 
a  success,  CIM  must  produce  $30  billion  in  predetermined  savings  between  1991 
and  1995.  [U.S.  Department  of  Defense,  1989]  Line  (functional)  managers  will  be 
responsible  for  executing  CIM  savings  and  since  money  has  already  been  cut  from 
the  ADP  (Automated  Data  Processing)  acquisition  budget,  there  is  no  choice  but  to 
realize  these  savings.  But  how?  Managers  faced  with  budget  cuts  are  scrambling  to 
apply  technology  to  automate  their  business  processes  to  make  them  more  efficient 
and  less  expensive,  but  the  CIM  (Corporate  Information  Management)  office  will 
not  approve  a  major  system  purchase  unless  the  system  applies  to  processes  that 
have  been  satisfactorily  evaluated  and  re-engineered.  Automating  an  inferior 
business  process  produces  a  more  sophisticated,  high-tech  configuration  of  an 
inferior  process  that  may  not  even  pay  for  itself,  let  alone  realize  any  significant 
savings.  Businesses  gain  strategic  advantage  by  changing  the  way  they  do 
business,  not  by  automating  old  or  inefficient  processes.  Cost  savings  are  realized 
not  only  from  automation  and  use  of  today’s  information  systems,  but  from 
evaluating  and  redesigning  business  processes  from  the  ground  up.  Automating 
the  process  may  be  desired  in  the  long  run,  but  managers  should  automate  a  well- 
designed/value-added  business  process. 

Modeling  is  used  to  evaluate  and  identify  changes  to  processes.  Many 
agencies  such  as  the  Army  Corps  of  Engineers  are  currently  using  the  IDEF 
modeling  methodology  to  model  their  business  processes.  The  CIM  office  raised 
the  question,  “can  the  process  of  improving  business  processes  be  modeled  to  gain 
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an  understanding  of  what  is  required  to  successfully  redesign  any  process?”  What 
this  question  is  really  asking  is  what  are  all  of  the  activities  associated  with  the 
redesign  process  itself  and  how  do  they  relate  to  one  another.  This  thesis  explores 
the  results  of  an  exercise  that  modeled  the  process  of  process  improvement. 

In  March  1992,  the  Redesign  Experts  and  Practices  (REAP)  team  was 
established.  This  team  was  tasked  to  model  the  business  redesign  model  itself 
using  the  IDEF  methodology.  Several  questions  led  to  the  successful  completion 
of  the  upper  level  model  of  this  process. 

( 1 )  What  is  a  process? 

(2)  What  are  the  activities  involved  in  successfully  evaluating  and 
redesigning  a  business  process? 

(3)  How  do  these  activities  relate  to  one  another  and  are  all  activities  required 
for  successful  redesign? 

(4)  What  does  a  typical  manager  (DoD  or  otherwise)  want  to  accomplish  and 
what  are  his/her  motivations? 

(5)  Are  we  modeling  the  actual  “How  To’s  (cookbook)”  of  process  redesign 
or  simply  initiating  and  organizing  the  “What’s  Needed”  to  perform 
successful  process  redesign? 

The  next  two  sections  summarize  the  history  of  the  IDEF  methodology  as  well 
as  describe  some  of  the  nomenclature  and  basic  tools  used.  Then  the  paper 
describes  how  the  REAP  team  assumed  the  task  of  modeling  the  process  for 
process  improvement  and  the  results  of  the  exercise.  Finally,  the  REAP  team’s 
observations  and  recommendations  are  discussed. 

B.  HISTORY  OF  CORPORATE  INFORMATION  MANAGEMENT  (CIM) 

Two  things  occurred  at  the  end  of  the  1980s  that  provided  profound 
implications  for  information  technology  in  the  Department  of  Defense  (DoD):  0) 
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Congress  became  displeased  with  DoD  management  of  information  technology 
and  (2)  the  conclusion  of  the  Cold  War  started  the  down-sizing  of  the  defense 
establishment. 

In  July  1989,  the  House  Armed  Services  Committee  responded  to  Government 
Accounting  Office  (GAO)  reports  of  mismanagement  of  automated  data 
processing  in  DoD  by  suggesting  that  funding  would  no  longer  be  forthcoming  for 
DoD  investments  in  information  technology  until  the  department  devised  a 
unified,  non-duplicative,  comprehensive  strategy  for  its  information  technology 
(IT).  DoD  was  then  spending  nine  billion  dollars  annually  on  IT  resources.  In 
response  to  Congressional  criticism,  the  Secretary  of  Defense  appointed  a  Deputy 
Secretary  (DSD),  with  vast  experience  from  the  private  sector,  to  manage  the  DoD 
comptroller  office.  The  DoD  comptroller  office  includes  the  office  of  DoD 
Information  Resources  Management  (IRM).  The  DSD  brought  with  him  a 
Corporate  Information  Management  (CIM)  strategy  that  was  being  implemented 
by  his  former  employer.  That  company  had  devised  CIM  to  bring  information 
resources  together  across  divisional  boundaries.  [Schweizer,  1991] 

In  November  1989,  a  CIM  office  was  created  under  the  DoD  deputy 
comptroller  for  IRM.  She  appointed  a  director  of  CIM  who  began  implementing 
the  DSD’s  recipe  for  unifying  and  standardizing  information  resources.  The 
emphasis  was  on  unification  and  standardization.  The  IT  strategies  to  be  devised 
by  CIM  were  to  be  conceived  at  the  DoD  level  rather  than  being  an  amalgam  of 
the  parochial  interests  and  historically-evolved  systems  of  the  individual  services 
and  agencies.  The  three  objectives  outlined  were: 

(1)  To  ensure  the  standardization,  quality,  and  consistency  of  data  from 
DoD’s  multiple  management  information  systems. 


3 


(2)  To  identify  and  implement  management  efficiencies  in  support  of 
business  areas  throughout  the  information  system  life  cycle. 

(3)  To  eliminate  duplication  of  efforts  in  the  development  of  multiple 
information  systems  designed  to  meet  a  single  functional  requirement. 
[Leong-Hong,  1990] 

For  FY  91  funding,  the  CIM  office  requested  $200  million  for  its  operating 
budget.  In  October,  1990  the  Senate  took  one  billion  dollars  out  of  the  IT  request 
in  the  Defense  Appropriations  Bill  and  gave  it  to  the  CIM  office  for  operations  and 
to  begin  implementation  of  CIM  initiatives.  The  bulk  of  this  billion  dollars  would 
be  returned  to  the  services  and  agencies  from  which  it  was  taken,  but  only  if  the 
systems  they  sought  to  fund  met  CIM  standards.  The  message  from  Capitol  Hill 
was  that  CIM  was  a  positive  response  to  Congressional  concerns  and  that  it  was 
being  rewarded  with  a  grant  of  veto  power  over  investments  in  IT  by  the  services 
and  federal  agencies.  An  added  message  was  that,  from  then  on,  proposals  for  IT 
acquisition  must  possess  the  inherent  capability  for  DoD-wide  integration  and 
standardization.  [Schweizer,  1991] 

In  December  1990,  the  Secretary  of  Defense  moved  the  CIM  office  from  the 
comptroller  office  and  placed  it  within  the  domain  of  the  Assistant  Secretary  of 
Defense  for  Command,  Control,  Communications  and  Intelligence  (ASD[C^1]). 
The  IRM  director  became  the  Deputy  Assistant  Secretary  for  Information  Systems. 
The  Defense  Communications  Agency  was  selected  as  the  action  agency  to 
embody  and  carry  out  the  CIM  program.  It  was  then  renamed  the  Defense 
Information  Systems  Agency.  [Schweizer,  1991] 

In  January  1991,  the  ASD(C^I)  created  the  position  of  Director  of  Defense 
Information  (DDI)  as  a  leadership  locus  for  IT  across  DoD.  An  IT  executive  from 
industry  of  national  repute  was  appointed  to  the  post  early  in  1991.  Within  six 


4 


months  of  his  appointment,  the  DDI,  who  was  the  author  of  books  on  information 
payoff  and  business  unit  practices,  began  to  expand  the  CIM  concept  to  encompass 
business  process  redesign.  The  message  from  the  DDI’s  office  was  that  if  DoD 
was  going  to  be  smaller  it  was  also  going  to  work  smarter.  Rather  than  making 
across-the-board  cuts  in  information  systems,  the  DDI  sought  to  squeeze  non¬ 
value-added  elements  out  of  business  processes.  Only  after  a  business  process  had 
been  redesigned  down  to  its  value-added  activities  would  it  be  considered  for 
automation.  [Schweizer,  1991] 

In  April  1991,  a  member  of  the  Naval  Postgraduate  School  (NPS)  department 
of  administrative  sciences  visited  the  DDI  to  explore  possibilities  for  CIM-funded 
research  into  information  systems.  The  DDI  proposed  that  NPS  could  assist  his 
office  by  undertaking  research  related  to  the  implementation  of  business  process 
redesign  in  DoD.  He  funded  a  research  project  to  be  undertaken  in  FY  92. 

In  February  1992,  a  special  assistant  to  the  DDI,  formerly  a  successful 
practitioner  of  business  process  redesign  with  the  Army  Corps  of  Engineers,  met 
with  NPS  representatives  in  Monterey  to  finalize  tasking  for  the  research  project. 
An  agreement  was  reached  in  which  a  NPS  faculty-student  research  team  would 
model  the  business  process  redesign  using  the  IDEF  modeling  tool.  The  resultant 
model  of  the  modeling  process  would  be  incorporated  into  a  guide  book  on 
process  redesign  for  DoD  functional  managers.  At  the  end  of  March,  1992,  the 
NPS  research  team,  joined  by  the  NPS  Dean  of  Computer  and  Information 
Services,  participated  in  a  five-day  IDEF  modeling  workshop  in  Monterey 
conducted  by  representatives  of  D.  Appleton  Company,  Incorporated.  The  team 
would  later  call  itself  REAP  (Redesign  Experts  and  Practices). 

The  REAP  team  consisted  of  three  research  students,  three  professors,  a  dean, 
and  two  facilitators  from  D.  Appleton  Company,  Incorporated.  The  REAP  team 
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decided  not  to  conduct  extensive  preliminary  research  pertaining  to  IDEF  prior  to 
the  conference.  The  reason  for  this  decision  was  to  avoid  biases  that  might  affect 
the  outcome  of  the  exercise. 

The  IDEF  conference  was  held  in  MarchC  1992  for  five  days.  The  team 
successfully  completed  a  model  of  the  activities  required  to  redesign  a  process. 
Additional  IDEF  conferences  are  scheduled  to  complete  the  model  down  to  its 
business  rule  level  and  write  the  redesign  handbook. 
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II.  IDEF  METHODOLOGY 


The  following  chapter  describes  why  IDEF  was  chosen  to  be  used  to  model 
the  process  improvement  process,  presents  a  biief  summary  of  what  IDEF  is,  and 
discusses  how  IDEF  functions. 

A.  THE  ENVIRONMENT 

As  functional  managers  are  faced  with  diminishing  budgets  and  the  axiom:  do 
more  with  less,  they  require  a  method  to  define  and  evaluate  their  business 
processes  to  detect  ways  to  improve  upon  them.  Managers  who  have  just  had  their 
budgets  reduced  require  imagination  when  planning  to  execute  their  missions  with 
fewer  resources.  No  comprehensive  instruction  manual  or  recipe  could  be  found 
that  describes  in  simple  terms  how  to  redesign  business  activities  more  efficiently. 
Books  do  exist  that  describe  various  facets  of  the  redesign  process,  such  as 
benchmarking.  However,  no  reference  could  be  found  that  has  put  together  all  of 
the  activ  ities  required  to  perform  a  capacious  evaluation  and  implement  changes  to 
a  process. 

The  IDEF  modeling  tool  was  chosen  by  the  REAP  team  to  create  a  model  of 
the  activities  to  perform  to  implement  change  because  the  IDEF  modeling  tool  will 
also  be  used  by  functional  managers  to  model  their  own  processes.  The  IDEF 
modeling  method  takes  an  activity  and  breaks  it  down  into  a  series  of  inputs, 
outputs,  mechanisms,  and  controls  (ICOM’s).  The  problem  the  REAP  team  faced 
while  using  IDEF  to  model  the  Process  Improvement  Process  (PIP),  is  that  an 
activity  did  not  yet  exist  to  model. 
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B.  DEFINING  A  PROCESS 

A  process  is  an  activity  that  occurs  over  time  and  transforms  inputs 
(information  or  materials)  into  recognizable  outputs.  The  terms  process,  activity, 
function,  and  task  are  synonymous  in  the  IDEF  methodology.  The  activity  is 
assisted  by  mechanisms  and  constrained  by  controls.  An  activity  could  be  as  large 
as  building  an  automobile  with  all  of  its  sub-processes  or  as  small  as  the  act  of 
approving  an  order.  An  activity  or  process  should  always  be  labeled  using  active 
verbs.  [D.  Appleton  Company,  Inc.,  1992] 

C.  IDEF  METHODOLOGY  EVOLUTION 

The  IDEF  methodology  was  developed  by  the  Air  Force  in  the  1970’s  because 
the  service  needed  to  increase  manufacturing  productivity  through  the  semantic 
application  of  information  technology.  IDEF  was  borne  from  the  Integrated 
Computer-Aided  Manufacturing  (ICAM)  Program.  It  is  currently  being  used  to 
define  advanced  concepts,  techniques,  and  procedures  for  developing  logical 
models  to  display  semantic  characteristics  of  business  activities  and  business  rules 
associated  with  data  structures.  [D.  Appleton  Company,  Inc.,  1992] 

IDEFO  is  used  to  define  the  broader  overall  business  activities  and  their 
relationship  to  one  another.  IDEF1X  is  used  to  define  the  actual  business  rules  that 
apply  to  the  lowest  level  activities.  Activity  Based  Costing  (ABC)  correlates 
business  processes  to  their  costs.  [D.  Appleton  Company,  Inc.,  1992]  These  costs 
may  be  used  to  evaluate  whether  or  not  to  implement  changes  based  on  expected 
savings. 

D.  THE  MODELING  PROCESS 

The  modeling  process  typically  begins  with  a  group  exercise.  The  group  has 
one  or  more  processes  to  evaluate  and  change  or  else  the  group  wants  to  build 
processes  from  scratch.  An  IDEF  expert  facilitator  explains  how  the  IDEF 
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modeling  process  operates  and  extracts  the  group’s  objectives.  The  facilitator  then 
asks  the  group  to  decide  which  objectives  are  critical  to  the  success  of  the  exercise. 

The  group  completes  the  model  of  the  process  from  the  top  down.  They  start 
with  the  broader  overall  process  using  node  trees  (a  hierarchical  view  of  the  upper 
level  activities)  and  identify  subprocesses  that  are  contained  within  each  node 
using  context  diagrams  (showing  only  one  activity  and  its  ICOM’s)  and 
decomposition  diagrams  (showing  an  entire  level  of  sub-activities  of  the  parent 
with  their  ICOM’s).  The  model  contains  a  glossary  that  defines  all  of  the  terms 
used  in  the  model.  The  lines  named  by  nouns  that  go  into  or  out  of  activity  boxes 
on  the  model  are  called  ICOM’s  (inputs,  controls,  outputs,  and  mechanisms). 

Although  IDEF  does  not  allow  for  sequencing  activities,  this  can  often  be 
implied  by  their  position  in  the  model.  For  example,  one  would  not  want  to 
“approve  an  order”  before  “receiving  an  order.” 

Appendix  A  contains  an  IDEF  handbook  (Reader’s  Guide)  that  explains  the 
basic  tools  and  methodology  used  in  an  IDEF  exercise. 
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III.  IDEF  EXERCISE  RESULTS 


Appendix  A  is  the  REAP  report.  It  contains  the  preliminary  model  of  the 
Process  Improvement  Process  as  well  as  the  data  definitions  and  ICOM 
definitions.  It  describes  in  detail  how  the  REAP  team  conducted  its  exercise  and 
explains  the  IDEF  methodology. 

IDEF  is  typically  used  to  model  manufacturing  processes.  However,  the 
REAP  team  was  not  tasked  to  model  a  manufacturing  process,  but  rather  to  model 
the  more  conceptual  process  of  improving  processes. 

The  REAP  team  used  the  group  accumulation  technique  to  develop  and 
improve  the  IDEF  model.  This  technique  was  both  a  strength  and  weakness  of  the 
IDEF  modeling  methodology.  Its  strength  lies  in  the  group  deliberation  of  all  ideas 
on  each  topic;  its  weakness  is  the  extensive  time  required  to  achieve  consensus.  As 
the  node  model  suggests.  Figure  (1),  the  REAP  team  determined  that  the  Process 
Improvement  Process  model  actually  consists  of  three  major  components: 

(1)  Create  a  Process  for  Improving  Process  Redesign,  which  actually  models 
the  process  of  creating  the  process  improvement  process. 

(2)  Pilot  a  project  using  the  Process  Redesign  Model  which  uses  the  Process 
Improvement  Model  to  improve  a  bona  fide  process  such  as  an  accounting 
system. 

(3)  Maintain  the  Model  uses  redesign  personnel’s  feedback  and  suggestions 
for  improvement  of  the  model  itself. 

The  REAP  team  decided  to  explore  only  the  first  node,  that  is,  the  Create  a 
Process  for  Improving  Process  Redesign.  The  Pilot  a  Process  for  Process  Redesign 
node  will  be  performed  by  another  thesis  student.  The  REAP  team  foresees  the 
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Maintenance  node  being  controlled  by  the  CIM  office  subsequent  to  the 
implementation  of  the  process  improvement  handbook. 


The  model  of  Create  a  Process  for  Improving  Process  Redesign  was  explored 
down  two  levels.  These  two  levels  were  able  to  identify  “what”  was  needed  to 
execute  the  redesign  process  effectively  (i.e.  the  chapter  titles  in  a  handbook  for 
functional  managers),  but  not  the  exact  steps  or  proven  methods  available  to 
actually  carry  out  each  of  these  activities.  (These  “how  to’s”  are  the  subject  of  a 
follow-on  IDEF  exercise  and  thesis.) 

The  IDEF  exercise  was  designed  to  build  a  foundation  or  shell  of  the  Process 
Improvement  Process  model.  To  avoid  confusion  when  reading  the  model  over  the 
next  few  pages  it  is  imperative  to  note  that  REAP  first  modeled  its  own  process, 
that  is,  the  process  of  defining  a  model  for  process  redesign.  Doing  this  resulted  in 
essentially  two  models  contained  in  one.  The  first,  higher  level  model  is  the 
“What”  model  describing  the  REAP  team’s  process  of  defining  and  refining  the 
process  improvement  model  itself.  Knowledge  and  experience  gained  by  the  team 
while  developing  each  activity  had  an  influence  on  the  development  of  the  other 
activities.  The  development  was  somewhat  circular  because  the  knowledge  and 
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experience  gained  during  the  exercise  was  used  frequently  to  refine  other 
activities  that  had  been  developed  earlier  in  the  week.  Figure  (2)  shows  the  upper 
level  decomposition  of  the  model. 

The  second,  deeper  model  is  the  “How  to”  model  that  still  needs  to  be 
completely  detailed  in  subsequent  IDEF  exercises.  Creating  the  model  this  way  led 
to  much  confusion  on  REAP’s  part  as  the  team  struggled  to  determine  which  “hat” 
applied  to  each  ICOM.  On  the  other  hand,  trying  to  develop  the  model  without  this 
top  layer  may  have  lead  to  an  incoherent  model.  The  team  first  had  to  identify 
what  it  was  using  to  develop  the  model  for  itself.  Without  this  information,  the 
model’s  foundation  could  not  be  understood  by  subsequent  team  members. 

The  IDEF  exercise  was  conducted  in  March  1992.  After  a  brief  introduction, 
the  facilitators  described  the  IDEF  methodology  itself.  The  team  members  were 
then  asked  to  state  the  desired  objectives  of  the  consultation.  After  determining  the 
desired  objectives,  the  team  was  then  asked  to  identify  issues  critical  to  the  success 
of  the  consultation.  The  REAP  team  considered  13  issues  to  be  critical: 

(1)  The  Process  Improvement  Process  (PIP)  must  be  applicable  to 
manufacturing  and  service  operations. 

(2)  The  PIP  will  be  presented  as  a  “cookbook”  guide  with  an  explanation  of 
the  underlying  theory. 

(3)  The  PIP  will  make  process  improvement  clear  and  accessible  to 
functional  managers. 

(4)  The  PIP  will  help  to  identify  meaningless  activities. 

(5)  The  PIP  will  be  operational. 

(6)  The  PIP  will  be  detailed  enough  to  be  implement  able. 

(7)  The  PIP  will  be  easily  modifiable. 
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(8)  The  PIP  will  either  identify  improvement  methods  or  a  method  for 
identifying  improvement  methods. 

(9)  The  PIP  will  be  generic  enough  to  be  applicable  across  different  levels  of 
management. 

(10)  The  PIP  will  help  identify  value-added  activities. 

(11)  The  deliverable  will  completely  describe  the  PIP. 

(12)  The  PIP  will  provide  functional  managers  with  a  way  to  envision 
alternatives  to  the  current  process  and  will  make  the  paradigm  shift 
obvious. 

(13)  The  existing  process  must  be  accurately  defined  in  PIP. 

Completing  all  of  these  critical  success  factors  was  quite  ambitious  for  a  five- 
day  exercise,  but  the  REAP  team  recognized  that  this  consultation  was  just  the 
beginning  of  a  long-term  project.  The  REAP  team  was  able  to  establish  the  shell 
for  the  PIP.  Because  the  shell  was  so  important  to  complete  precisely,  most  of  the 
week  was  spent  deliberating  its  adequacy  and  accuracy.  The  REAP  team  wanted  to 
keep  the  model  as  simple  as  possible,  but  the  team  wanted  to  be  confident  that  the 
model  was  also  legitimate.  The  REAP  team  envisioned  a  handbook  that  was 
concise  so  managers  would  actually  read  and  use  it.  If  supplementary  information 
and  further  explanation  were  needed,  the  handbook  would  provide  the  manager 
with  references  and  an  extensive  bibliography. 

There  are  five  major  activities  that  the  REAP  team  determined  must  be 
included  in  the  handbook  to  implement  redesign  changes  effectively.  See  Figure 
(3).  They  are: 

( 1 )  describe  how  to  marshal  resources, 

(2)  describe  how  to  create  an  environment  for  discontinuous  thinking, 

(3)  describe  how  to  understand  “AS-IS”  processes, 
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(4)  describe  how  to  evaluate  a  process,  and 

(5)  describe  how  to  implement  changes. 


The  following  activity  descriptions  from  the  model  could  be  compared  to 
chapters  and  sub-chapter  titles  in  a  future  handbook  on  how  to  improve  processes. 

(Al)  The  Describe  How  to  Marshall  Resources  process  use  REAP’s 
knowledge,  experience,  and  other  necessary  resources  to  develop  a 
framework  for  assembling  and  organizing  the  resources  necessary  to 
initiate  and  accomplish  process  redesign.  These  resources  include,  but 
are  not  limited  to  people,  funds,  seminars,  technology,  and  ideas.  A 
functional  manager  responsible  for  bringing  about  process  redesign  will 
be  unable  to  model  or  portray  existing  AS-IS  processes  if  he  does  not 
understand  how  to  gather  the  resources  to  undertake  the  project.  The 
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extent  of  this  knowledge  will  affect  the  amount  of  resources  that  can  be 
brought  to  bear  in  the  effort  to  understand  process  change. 

Included  in  the  Describe  How  to  Marshall  Resources  activity  are  the  following 
sub-activities: 

(All)  The  Define  Process  Improvement  Resources  process  describes 
how  to  determine  what  resources  are  available  to  accomplish 
process  redesign. 

(A  12)  The  Describe  How  to  Select  Process  Improvement  Resources 
process  describes  how  to  choose  those  resources  appropriate  for 
the  given  redesign  process. 

(A13)  The  Describe  How  to  Compare  What’s  Needed  to  Existing 
Resources  process  describes  how  to  evaluate  what  resources  are 
lacking,  if  any.  For  example,  inventories  of  skills,  knowledge, 
and  experience  (both  needed  and  available)  must  be  taken  and 
compared  to  identify  deficiencies.  Specific  tools  for  evaluating 
these  resources  and  converting  one  resource  to  another  must  be 
addressed. 

(A  14)  The  Describe  How  to  Acquire  Resources  process  describes  how 
to  obtain  or  appropriate  resources  which  are  lacking. 

(A15)  The  Describe  How  to  Apply  Resources  process  describes  how  to 
put  to  use  the  resources  which  are  necessary  for  process  redesign. 

(A  16)  The  Describe  How  to  Measure  Resource  Utilization  process 
describes  how  to  evaluate  resources  for  bringing  about  the 
desired  process  redesign. 

(A2)  A  functional  manager  responsible  for  bringing  about  process  redesign 
may  not  be  able  to  execute  the  process  if  he  or  she  cannot  assemble  a 
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team  with  the  requisite  group  diversity,  temperament  and  social  skills  to 
deal  with  redesign  issues  with  a  broad  commitment  to  action.  The  (A2) 
Describe  How  to  Create  an  Environment  for  Discontinuous  Thinking 
process  uses  REAP’s  knowledge  and  experience  of  encouraging  creative 
thinking  to  explain  to  a  functional  manager  how  to  overcome  that 
deficiency  through  training  or  facilitation  and  the  use  of  technology. 

Included  in  the  Create  an  Environment  for  Discontinuous  Thinking  activity 
are  the  following  sub-activities: 

(A21)  The  Describe  How  to  Avoid  a  Threatening,  Hostile  Environment 
process  explains  both  how  to  initiate  and  sustain  an  environment 
that  facilitates  the  open  exchange  of  ideas. 

(A22)  The  Describe  How  to  Expand  Viewpoint  process  explains  how  to 
facilitate  the  understanding  and  adoption  of  new  perspectives  by 
those  individuals  participating  in  the  process  improvement 
process. 

(A23)  The  Describe  How  to  Encourage  Creative  Thinking  process 
explains  how  to  facilitate  innovative  solutions  among  the 
individuals  participating  in  the  process  improvement  process. 

(A24)  The  Describe  How  to  Promote  Involvement  process  explains  how 
to  engender  active  participation  in  the  individuals  participating  in 
the  process  improvement  process. 

(A25)  The  Describe  How  to  Promote  Cross  Functional  Thinking 
process  explains  how  to  facilitate  positive  interaction  across  areas 
of  responsibility,  e.g.,  including  extending  process  analysis  to 
process  interfaces. 
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(A3)  The  Describe  How  to  Understand  AS-IS  Processes  uses  REAP’s 
knowledge  and  experience  of  portraying  an  existing  work  process  using 
methods  and  processes  to  render  them  understandable  and  accessible  by 
functional  managers  contemplating  the  redesign  of  their  business 
operations. 

Included  in  the  Describe  How  to  Understand  AS-IS  Processes  activity  are  the 
following  sub-activities: 

(A31)  The  Describe  How  to  Define  a  Process  describes  how  to  model 
and  portray  an  activity  accurately  as  it  exists  now.  This  process 
includes  the  work  of  measuring  the  value  added  by  activities  and 
identifying  deficiencies  in  a  process. 

(A32)  The  Describe  How  to  Define  Process  Interfaces  process  describes 
how  to  define  the  interfaces  between  the  activities  that  are  being 
modeled  and  portrayed  and  those  tangential,  peripheral  activities 
with  which  the  modeled  activities  exchange  inputs,  constraints, 
outputs  or  mechanisms.  This  process  includes  an  examination  of 
relationships  between  activities  that  are  gathered  under  activity 
context  descriptions  at  a  higher  level  of  abstraction  during  a 
modeling  project. 

(A33)  The  Describe  How  to  Define  Data  Rules  process  describes  how 
to  define  rules  for  data  meaning  and  usage  in  the  databases  that 
support  existing  activities. 

(A34)  The  Describe  How  to  Define  Data  Standards  process  describes 
how  to  define  standards  for  data  elements,  including  storage, 
format,  and  media. 
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(A4)  The  Describe  How  to  Evaluate  a  Process  uses  REAP’s  knowledge  and 
experience  to  provide  an  explanation  of  means  by  which  a  process  can 
be  measured  and  judged.  The  extent  of  this  comprehension  will  affect 
the  level  of  understanding  of  the  selection  of  criteria  and  methods 
employed  in  business  process  evaluation. 

Included  in  the  Describe  How  to  Evaluate  a  Process  activity  are  the  following 
sub-activities: 

(A41)  The  Describe  How  to  Select  a  Process  to  Improve 
process  provides  a  description  of  procedures  involved  in 
discerning  which  processes  will  have  a  positive  impact  if 
improved. 

(A42)  The  Describe  How  to  Measure  Process  Performance  provides  a 
description  of  the  methods  and  instruments  used  to  measure 
various  process  efficiencies,  such  as  activity  based  costing, 
quality  function  deployment,  benchmarking,  and  activity  based 
analysis. 

(A43)  The  Describe  How  to  Pick  a  Measure  process  describes  the 
various  metrics  and  why  they  are  used  to  assess  corresponding 
processes. 

(A5)  The  Describe  How  to  Implement  Change  process  uses  the  REAP 
experience  base,  its  understanding  of  change  doctrine  and  long  range 
DoD  strategy  to  describe  to  functional  DoD  managers  of  all  levels  how 
to  implement  change.  The  metrics  developed  from  this  process  are  used 
to  improve  REAP’s  process  for  improving  the  DoD  Process 
Improvement  Process  (PIP). 
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Included  in  the  Describe  How  to  Implement  Change  activity  are  the  following 
sub-activities: 

(A51)  The  Describe  How  to  Select  Improvement  Method  process  uses 
REAP’s  understanding  of  improvement  methods  and  the  DoD 
environment  to  produce  a  guide  for  selecting  a  method  and 
improving  a  process.  It  helps  the  manager  evaluate 
characteristics  of  the  process  change  environment  surrounding 
the  process  and  selects  an  appropriate  method  for  implementing 
the  change. 

(A52)  The  Describe  How  to  Simulate  Future  Performance  process  uses 
REAP’s  understanding  of  enterprise  modeling  and  simulation 
methods  to  produce  a  guide  for  DoD  managers  wishing  to 
simulate  the  effects  of  changes  to  processes  and  how  those 
changes  affect  an  organization,  the  changed  processes,  and  other 
processes  in  an  organization. 

(A53)  The  Describe  How  to  Conduct  Change  process  uses  REAP’s 
understanding  of  change  methods  to  produce  a  guide  for  DoD 
managers  planning  or  conducting  a  change  to  a  process.  It 
includes  organizational,  personnel,  tasking,  information,  and 
resourcing  guidelines  for  particular  change  characteristics. 

(A54)  The  Describe  How  to  Measure  Change  Impact  process  uses 
REAP’s  understanding  of  change  methods  to  produce  a  guide  for 
DoD  managers  planning  to  measure  the  effects  of  a  process 
change.  It  includes  candidate  measurable  characteristics  and 
provides  mechanisms  for  measurements.  It  also  includes 
information  about  when  and  where  to  take  the  measurements. 
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who  should  take  the  measurements,  and  what  to  do  with  the 
measurements.  It  includes  information  on  testing  and  validating 
measurements  and  methods  to  improve  the  measurement  process. 

Most  of  the  IDEF  exercise  was  spent  deliberating  the  major  activities  that 
were  required  to  complete  a  successful  process  redesign.  Each  of  the  five  major 
activities  and  their  subactivities  were  finally  agreed  upon  and  were  evaluated 
countless  times  to  ensure  their  accuracy. 
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VI.  OBSERVATIONS  AND  RECOMMENDATIONS  REGARDING 
THE  PROCESS  IMPROVEMENT  PROCESS  AND  IDEF 


The  REAP  team  raised  several  issues  after  the  seminar  that  should  be 
addressed  at  subsequent  IDEF  exercises  as  well  as  by  managers  who  are  about  to 
undertake  the  process  improvement  process. 

A.  ENCOURAGING  RESULTS 

The  results  of  the  first  IDEF  conference  are  indeed  encouraging.  The  REAP 
team  is  convinced  that  the  process  of  process  improvement  has  been  modeled 
accurately  using  IDEF  and  can  be  described  in  a  handbook  for  functional 
managers.  IDEFO,  despite  its  difficulties  as  an  exercise,  proved  to  be  a  useful  tool 
for  focusing  the  communications  and  flow  of  contributions  among  redesign  team 
members.  IDEFO  provides  a  common  language  and  needed  structure  which  is 
absent  in  free-format  techniques  such  as  brainstorming. 

B.  TOP  LEVEL  MANAGEMENT  COMMITMENT 

If  top  level  management  commitment  is  missing  when  initiating  process 
evaluation,  then  middle  managers  will  have  an  almost  impossible  task  at  hand.  An 
observation  made  by  the  consultants  is  that  functional  managers  and  military 
commands  are  not  likely  to  incur  the  opportunity  costs  of  nominating  their  best 
staff  members  for  participation  in  a  process  redesign  effort.  Indeed,  to  minimize 
opportunity  costs,  they  are  likely  to  nominate  their  least  capable  personnel.  To  the 
extent  that  this  inclination  is  exercised,  the  quality  and  impact  of  a  recommended 
redesign  are  likely  to  be  less  than  what  the  CIM  initiatives  require  or  envision. 
This  problem  needs  to  be  addressed  to  find  ways  to  induce  functional  managers 
and  commands  to  nominate  their  most  qualified  staff  members  for  participation  in 
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process  redesigns.  The  Navy  Total  Quality  Leadership  (TQL)  program  has 
appeared  to  overcome  this  problem  by  requiring  the  highest  ranking  personnel 
(Admirals  and  Captains)  to  attend  TQL  seminars  prior  to  tasking  the  troops.  The 
highest  ranking  personnel  may  not  be  the  most  appropriate  to  attend  an  IDEF 
exercise,  but  an  attempt  should  be  made  to  ascertain  the  most  qualified  personnel 
and  use  them  in  the  IDEF  exercises. 

Because  managers  may  be  uniformed  about  (1)  the  technique  of  modeling  a 
process,  (2)  the  crucial  nature  of  process  redesign  in  the  CIM  scheme  or  (3)  what 
CIM  itself  is  all  about,  the  REAP  team  recommends  that  the  CIM  office  produce  a 
twenty-minute  videocassette  that  addresses  the  gaps  in  what  functional  managers 
are  likely  to  know  about  CIM  or  PIP.  REAP  does  not  believe  that  manuals,  guides, 
lectures  or  seminars  will  suffice. 

C.  STAFFING  THE  IDEF  TEAM 

In  addition  to  committing  the  best  people  to  attend  an  IDEF  exercise,  what 
other  criteria  should  be  addressed  to  ensure  success?  Are  executives,  managers, 
workers,  complete  outsiders,  or  any  combination  of  the  above  particularly  desired 
on  the  IDEF  team?  An  individual’s  experience  and  viewpoint  may  have  a 
profound  affect  on  the  outcome  of  the  seminar.  A  person  who  works  closely  with  a 
process  may  know  its  inherent  strengths  and  weaknesses  better  than  an  executive 
who  reads  an  occasional  report  produced  during  that  process.  However,  the 
executive  who  reads  the  occasional  report  may  know  more  about  the  strategic 
directions  of  the  company  and  how  the  process  being  evaluated  relates  to  other 
processes  within  the  company.  The  worker  may  only  be  an  expert  within  his  own 
niche. 

Even  an  individual’s  personality  may  be  considered  as  to  whether  he  has  the 
appropriate  temperament  for  progressing  through  a  seminar.  Tests  exist,  their 
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usefulness  somewhat  debatable,  that  may  be  used  to  determine  a  candidates  IDEF 
reliability.  Some  personalities  are  ill-suited  to  the  level  of  detail  and  frequent 
tedium  of  the  modeling  process.  Others  seem  quite  at  ease  with  these  aspects  of 
the  modeling  process.  Ill-suited  personalities  undermine  the  productivity  and 
effectiveness  of  IDEF  teams.  A  review  of  the  literature  of  the  social  psychology  of 
small  group  effectiveness  to  determine  what  is  already  known  about  this  issue  and 
a  set  of  experiments  testing  the  composition  of  modeling  teams  of  various 
personality  mixes  should  be  conducted  as  soon  as  possible. 

D.  INCENTIVES  FOR  FUNCTIONAL  MANAGERS  TO  REDESIGN 

PROCESSES 

Assuming  that  functional  managers  and  commanders  are  overburdened  with 
responsibilities,  ad  hoc  taskings,  mandated  stand-downs,  and  nagging  urgencies, 
they  will  naturally  try  to  reduce  the  time  and  attention  costs  for  redesign  efforts 
needed  to  satisfy  the  CIM  requirement.  If  a  manager  cannot  readily  see  the  value 
of  a  particular  program  they  most  likely  will  not  give  the  program  their  premium 
effort.  The  issues  are: 

(1)  What  incentives  exist  or  ought  to  exist  for  them  to  produce  any  redesign 

effort  beyond  the  minimum? 

(2)  How  can  the  CIM  office  mount  a  leadership  effort  that  emulates  the 

success  of  TQL? 

E.  WEAKNESSES  OF  IDEF 

Is  IDEF  indeed  the  invincible  tool  for  process  improvement?  IDEF  does  have 
its  weaknesses.  The  linearity  of  the  IDEF  process  may  lead  to  inefficient  use  of 
time.  Consensus  is  often  difficult  to  achieve  and  the  entire  process  may  come  to  a 
screeching  halt  because  several  members  cannot  reach  an  agreement  on  a  minor 
issue.  In  the  PIP  model,  each  activity’s  relationship  to  one  another  gave  cause  for 
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concern.  The  enhanced  knowledge  and  experience  (output)  gained  while  creating 
each  activity  was  considered  a  control  (limiting  factor)  on  creating  each  of  the 
other  activities.  These  outputs  and  controls  may  be  seen  in  Figure  (2).  It  could  also 
be  considered  a  mechanism  because  it  supports  creating  other  activities.  Although 
of  minimal  importance  to  the  overall  model,  deliberation  of  how  this  knowledge 
and  experience  affected  other  activities  consumed  excessive  time.  Unfortunately 
the  facilitators  allowed  the  REAP  team  to  debate  this  issue  long  past  its  useful 
completion.  IDEF  exercise  teams  must  take  care  not  to  allow  minor  issues  to 
undermine  successful  completion  of  their  objectives.  In  any  group  situation,  the 
facilitator  must  keep  the  group  focused  on  important  issues  and  not  allow  the 
group  to  go  off  on  a  tangent  for  any  length  of  time. 

Group  consensus  certainly  does  not  guarantee  accuracy  and  often  group 
members  resort  to  decision  making  by  hierarchy  and  job  title  (who  has  the 
authority  to  decide  this?)  rather  than  reaching  a  true  consensus  among  themselves. 
This  is  an  artifact  of  their  normal  everyday  decision  making.  Nonetheless  it  erodes 
the  potential  of  IDEF  and  other  tools  to  usefully  model  a  process.  Further  study 
needs  to  be  conducted  on  existing  literature  on  small  group  processes  to  reveal 
what  is  known  about  this  tendency  and  what  can  be  done  to  overcome  it.  This 
issue  is  a  key  element  in  the  A2  activity  in  our  PIP  model  (Create  an  Environment 
for  Discontinuous  Thinking). 

Furthermore,  there  are  many  other  stand-alone  techniques  that  a  manager  may 
use,  such  as  benchmarking,  to  assist  in  evaluating  and  changing  his  processes. 
IDEF  is  time  and  resource  exhausting. 

F.  MODELING  THE  “AS-IS”  VERSUS  NOT  MODELING  THE  “AS-IS” 

Does  analyzing  the  “as- is”  doom  the  IDEF  methodology  to  rebuild  a  weak 
process  with  some  minor  refinements?  Evaluating  the  “as-is”  certainly  may  lead  to 


25 


biases  as  the  team  considers  the  way  the  process  is  currently  being  done.  A  group 
of  independent  consultants  or  even  employees  completely  unfamiliar  with  the 
current  process  could  conceivably  build  a  better  process  from  the  ground  up  with 
no  biases  based  on  the  past.  For  example,  a  group  of  engineering  graduates  are 
hired  by  a  company  who  manufactures  steel.  This  company  has  been  producing 
steel  for  over  fifty  years  in  an  obsolete  factory.  The  company  hires  the  engineering 
graduates  to  design  a  new  factory  with  no  knowledge  of  how  the  steel  is  currently 
being  produced.  They  create  a  design  that  is  state-of-the-art  technology  that  is  far 
more  effective  than  anything  the  long-term  company  engineers  could  dream  of. 
The  opposite  situation  could  happen  in  an  environment  where  corporate 
knowledge  is  more  important  in  the  design  of  the  process.  Whether  or  not  to 
evaluate  the  “as-is”  process  is  indeed  an  important  consideration  before  embarking 
on  an  IDEF  seminar.  If  the  personnel  involved  are  already  familiar  with  the 
current  process,  then  evaluating  the  “as-is”  process  will  most  likely  be  beneficial 
because  their  experiences  and  biases  will  be  inherent  in  their  opinions  on  how  to 
redesign  the  process.  Another  possibility  exists  to  do  both  an  IDEF  with  the  “as- 
is”  analysis  and  one  without  the  “as-is”  analysis.  This  concept  is  obviously  more 
expensive  than  just  doing  it  one  way  or  the  other.  However,  having  two  viable 
models  to  redesign  a  process  should  be  better  than  one  if  a  manager  can  harvest 
the  strengths  and  eliminate  the  weaknesses  from  both  models. 

G,  SUBSEQUENT  REAP  TEAM  IDEF  EXERCISES 

The  next  REAP  team  report  should  carefully  consider  the  transition  from  the 
“as-is”  to  the  “what-if.”  Cost-benefit  analysis  will  be  paramount  in  confining  “pie- 
in-the-sky”  ideas  from  being  implemented  before  there  actual  benefits  are 
evaluated. 
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While  the  REAP  team  strongly  believes  that  it  has  come  up  with  a  framework 
for  PIP  that  is  both  comprehensive  and  correct,  the  team  recommends  that  the  CIM 
office  sponsor  further  refinement  of  the  model.  The  REAP  team  at  the  Naval 
Postgraduate  School  (NPS)  is  already  directing  thesis  studies  that  will  detail 
activities  A2  (Create  an  Environment  for  Discontinuous  Thinking),  A3  (Design  the 
Process),  and  A4  (Implement  the  Change)  with  elements  on  the  “how’s”  of  their 
subactivities. 

H.  POPULATING  THE  REAP  DATABASE 

The  PIP  model  that  has  emerged  relies  heavily  on  the  existence  of  a  REAP 
database  to  support  redesign  teams  with  examples  of  other  successful  redesigns  in 
similar  endeavors.  The  prototype  database  is  concurrently  being  developed  by 
another  member  of  the  REAP  team.  As  presently  envisioned,  the  REAP  database 
architecture  would  be  institutionalized  as  a  database  in  the  CIM  office  where  it 
would  be  maintained  and  populated  with  data  entries.  Feasible  methodologies  by 
which  to  populate  the  database  should  be  devised  including  establishing  quality 
standards  for  admitting  a  reference  as  a  record  entry.  Software  lifecycle 
maintenance  and  database  editing  must  also  be  considered. 

I.  CONCLUDING  REMARKS 

The  REAP  team  is  convinced  it  has  created  a  model  that  is  comprehensive  and 
accurate.  Expansion  of  this  model  down  to  its  data  element  level  will  be  the 
subject  of  follow-on  study  and  IDEF  exercises.  Eventually  a  handbook  for 
functional  managers  will  be  written  that  will  explain  each  of  the  activities  and  the 
various  options  available  for  the  manager  to  employ  during  process  redesign. 
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Executive  Summary 


Two  things  happened  at  the  end  of  the  1980s 
that  had  profound  implications  for  information 
technology  in  the  Department  of  Defense 
(DOD):  (1)  Congress  became  displeased  with 
DOD  management  of  information  technology 
and  (2)  the  end  of  the  Cold  War  started  the 
down-sizing  of  the  defense  establishment. 

In  July,  1989,  the  House  Armed  Services 
Committee  responded  to  GAO  reports  of 
mismanagement  of  automated  data  processing 
in  DOD  by  suggesting  that  funding  would  no 
longer  be  forthcoming  for  DOD  investments  in 
information  technology  until  the  department 
devised  a  unified,  non-duplicative, 
comprehensive  strategy  for  its  information 
technology  (IT).  DOD  was  spending  nine 
billion  dollars  annually  on  IT  resources.  In 
response  to  Congressional  criticism,  the 
Secretary  of  Defense  appointed  a  Deputy 
Secretary  (DSD)  from  the  private  sector  to 
manage  the  DOD  comptroller  office,  which 
included  the  office  of  DOD  information 
resources  management  (IRM).  The  DSD 
brought  with  him  a  corporate  information 
management  (CIM)  strategy  that  was  being 
implemented  by  his  former  employer.  That 
company  devised  CIM  to  bring  information 
resources  together  across  divisional 
boundaries. 

In  November,  1989,  a  CIM  office  was  created 
under  the  DOD  deputy  comptroller  for  IRM. 
She  appointed  a  director  of  CIM  who  began 
implementing  the  DSD's  recipe  for  unifying 
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and  standardizing  information  resources.  The 
emphasis  was  on  unified  and  standardized. 

The  IT  strategies  to  be  devised  by  CIM  were  to 
be  conceived  at  the  DOD  level  rather  than 
being  an  amalgam  of  the  parochial  interests 
and  historically-evolved  systems  of  the 
individual  services  and  agencies. 

For  FY  91  funding,  the  CIM  office  requested 
$200  million  for  its  operating  budget.  In 
October,  1990  the  Senate  took  one  billion 
dollars  out  of  the  IT  request  in  the  Defense 
Appropriations  Bill  and  gave  it  to  the  CIM 
office  for  operations  and  to  begin 
implementation  of  CIM  initiatives.  The  bulk  of 
this  billion  dollars  would  be  returned  to  the 
services  and  agencies  from  which  it  was  taken, 
but  only  if  the  systems  they  sought  to  fund  met 
CIM  standards.  The  message  from  Capitol  Hill 
was  that  CIM  was  a  positive  response  to 
Congressional  concerns  and  that  it  was  being 
rewarded  with  a  grant  of  veto  power  over 
investments  in  IT  by  the  services  and  agencies. 
An  added  message  was  that,  from  then  on, 
proposals  for  IT  must  possess  the  capability  for 
DOD-wide  integration  and  standardization. 

In  December,  1990,  the  Secretary  of  Defense 
moved  the  CIM  office  from  the  comptroller 
office  and  placed  it  within  the  domain  of  the 
Assistant  Secretary  of  Defense  for  command, 
control,  communications  and  intelligence 
(ASD[C3I]).  The  IRM  director  became  the 
Deputy  Assistant  Secretary  for  information 
systems.  The  Defense  Communications  Agency 
was  selected  as  the  action  agency  to  embody 
and  carry  out  the  CIM  program.  It  was 
renamed  the  Defense  Information  Systems 
Agency. 
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In  January,  1991  the  ASD(C3I)  created  the 
position  of  Director  of  Defense  Information 
(DDI)  as  a  leadership  locus  for  IT  across  DOD. 
An  IT  executive  from  industry  of  national 
repute  was  appointed  to  the  post  early  in  1991. 
Within  six  months  of  his  appointment,  the 
DDI,  who  was  the  author  of  books  on 
information  payoff  and  business  unit  practices, 
began  to  expand  the  CIM  concept  to 
encompass  business  process  redesign.  The 
message  from  the  DDI's  office  was  that  if  DOD 
was  going  to  be  smaller  it  was  also  going  to 
work  smarter.  Rather  than  making  across-the- 
board  cuts  in  information  systems,  the  DDI 
sought  to  squeeze  non-value-added  elements 
out  of  business  processes.  Only  after  a  business 
process  had  been  redesigned  down  to  its  value- 
added  activities  would  it  be  considered  for 
automation. 

In  April,  1991,  a  member  of  the  Naval 
Postgraduate  School  (NPS)  department  of 
administrative  sciences  visited  the  DDI  to 
explore  possibilities  for  CIM-funded  research 
into  information  systems.  The  DDI  proposed 
that  NPS  could  assist  his  office  by  undertaking 
research  related  to  the  implementation  of 
business  process  redesign  in  DOD.  He 
funded  a  research  project  to  be  undertaken  in 
FY  92. 

In  February,  1992,  a  special  assistant  to  the 
DDI,  formerly  a  successful  practitioner  of 
business  process  redesign  with  the  Army 
Corps  of  Engineers,  met  with  NPS 
representatives  in  Monterey  to  finalize  taskings 
for  the  research  project.  An  agreement  was 
reached  in  which  a  NPS  faculty-student 
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research  team  would  model  the  "how"  of 
business  process  redesign  using  the  IDEF 
modeling  tool.  The  resultant  model  of  the 
modeling  process  would  be  incorporated  into  a 
guide  book  on  process  redesign  for  DOD 
functional  managers.  At  the  end  of  March, 

1992,  the  NPS  research  team,  joined  by  the  NPS 
Dean  of  Computer  and  Information  Services, 
participated  in  a  five-day  IDEF  modeling 
workshop  in  Monterey  conducted  by 
representatives  of  D.  Appleton  Company,  Inc. 


Mission 

The  Redesign  Experts  and  Practices  (REAP) 
Team  received  its  detailed  charter  to  produce  a 
quality  model  of  the  Process  Improvement 
Process  (PEP)  using  IDEFO  modeling 
techniques. 

1.  To  model  the  "how"  of  business 
process  redesign  steps,  creating  a 
model  of  the  redesign  process 
model  itself  that  can  be  used  in  the 
handbook  on  business  process 
redesign  for  functional  managers. 

This  model  is  to  be  constructed 
using  IDEF  techniques  by  10  May 
92. 

2.  To  develop  a  data  structure 
(business  rules),  from  general  to 
specific  aspects  of  an  organization, 
of  what  functional  managers  can 
realistically  expect  to  do.  The 
structure  is  to  take  the  form  of  an 
entity-relation  diagram.  This  is 
expected  to  be  a  long-term  project. 
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Estimated  completion  date: 
unknown. 

3.  To  develop  an  inventory  of 
alternative  resources  and  inputs  to 
be  used  by  redesign  teams  to  assist 
them  in  breaking  the  crust  of 
customs  and  convention  in  business 
processes.  The  means  by  which 
redesign  teams  can  identify  and 
discover  these  resources  will  be  a 
database.  The  scope,  configuration, 
design,  architecture,  ownership,  and 
maintenance  of  this  database  are 
issues  to  be  addressed  during  IDEF 
modeling.  A  prototype  of  this 
database  has  an  expected 
completion  date  of  1  September 
1992. 

4.  To  demonstrate  the  capability  of 
redesign  business  processes  through 
an  integrating,  comprehensive  case 
study  of  applied  redesign  to  a  single 
business  system,  i.e.,  civilian 
payroll.  Expected  completion  date  is 
1  December  1992. 

5.  To  prepare  a  final  report  that  will 
include  the  deliverables  described  in 
tasks  1-4  as  well  as  suggested 
follow-on  reports. 
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Workshop  Scope 


Daily  Schedule 


The  scope  for  this  workshop  is  limited  to 
number  (1)  from  above:  to  provide  the  REAP 
with  an  orientation  in  IDEFO  activity  modeling 
and  Activity  Based  Costing  (ABC).  The  model 
and  initial  performance  metrics  will  be 
documented  in  the  PIP  plan  that  is  the  primary 
deliverable  for  the  workshop. 


Day  1:  Kickoff  and  IDEFO  orientation. 
Establishment  of  workshop  mission, 
scope,  and  objectives.  Workshop 
expectations  set. 

Days  2/3:  Development  of  high-level 
IDEFO  Model.  ABC  orientation. 

Day  4:  Identification  of  major  activities 
and  primary  outputs  for  application 
of  ABC  techniques  to  follow  on 
projects.  Preparation  of  PIP  plan 
and  workshop  report  begun. 

Day  5:  Completion  of  model 
documentation  and  workshop 
report.  Reviewed  issues  and 
recommended  actions. 

The  REAP  continued  to  display  diversity  and 
full  participation  throughout  the  five  days.  It  is 
expected  that  the  group  will  continue  to 
develop  its  model,  but  the  group  may  change 
its  personnel  somewhat  upon  completion  of 
the  original  activity  from  21-25  March  1992. 
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Findings 

The  model  was  created  and  then  refined  many 
times  through  the  course  of  the  week.  As  the 
root  node  was  decomposed  it  became  obvious 
that  the  immediate  branch  nodes  would 
include  activities  that  REAP  could  not  explore 
thoroughly  during  the  five  day  constraint. 


A-i 

Provide  a  Process 
for  Process  Redesign 


Figure  1:  Context  for  REAP  Modeling  Effort 

The  "Create  a  Process  for  Process  Redesign" 
activity  was  developed  and  stabilized  down 
two  levels.  The  "Pilot  Process  for  Process 
Redesign"  activity  will  test  the  process 
redesign  model  by  applying  the  output  to  an 
actual  single  business  system.  The  "Maintain 
Process  for  Process  for  Process  Redesign" 
activity  will  include  the  long-term  update  and 
refinements  of  the  model  using  feedback  from 
the  users  and  will  most  likely  by  handled  by 
the  CIM  office. 

One  of  the  criticisms  of  REAP  is  that  it  did  not 
spend  time  creating  any  data  models  or 
business  rules.  The  counter-argument  to  this 
criticism  is  that  these  rules  will  be  inherent  in 
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lower  levels  of  the  model  when  they  are 
detailed. 

ABC  was  not  discussed  due  to  time  constraints. 

The  answer  to  the  original  research  question 
(can  the  process  improvement  model  be 
modeled?)  was  answered  positively.  The 
model  is  being  built  successfully  and  its 
completion  will  include  a  viable  working 
handbook  on  specifically  how  to  improve 
processes  in  one's  functional  area. 

IDEF  is  a  useful  tool  to  model  the  process 
improvement  process.  It  is  not  without  its 
limitations,  however. 

IDEF  modeling  is  manpower  intensive, 
difficult  to  set  consistent  policy,  and  requires 
long-term  commitment  to  attain  a  complete 
model  of  any  complex  process. 


Recommendation 

The  REAP  Team  recommends  that  the  Office  of 
the  Director  of  Defense  Information  develop  a 
maintenance  module  for  the  process  redesign 
process.  The  model  should  include  a  business 
rule  model. 


REAP  Team  Profile 


Barry  Frew,  Dean  of  Computer  and 
Information  Services 

Kenneth  Euske,  Associate  Professor  of 
Accounting 
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William  Haga,  Adjunct  Professor  of 
Management  Information  Systems 

Jeff  Nevels,  LCDR,  SC,  USN,  Instructor 
of  Accounting 

Scott  White,  LCDR,  USN,  Aviator 

Diane  Bizzell,  LT,  USN,  General 
Unrestricted  Line 

William  Kotheimer,  LT,  USN,  Naval 
Intelligence 

Gene  Honbo,  D.  Appleton  Company, 
Inc. 

Eric  Bails,  D.  Appleton  Company,  Inc. 
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Approach  to  Process  Modeling 


This  workshop  was  conducted  as  a  standard 
engagement  offered  by  D.  Appleton  Company 
to  provide  modeling  support  to  business 
process  improvement  efforts  under  the  DOD 
CIM  umbrella.  A  description  of  the  standard 
engagement  appears  below. 


CIM  Business  Process  Improvement  Workshops 

Scoping  Workshop  (one  week!  -  This  workshop  is 
designed  to  provide  DOD  functional  executives 
and  managers  with  an  understanding  of  the 
business  process  improvement  objectives 
associated  with  the  CIM  initiative.  The 
participants  will  receive  an  orientation  in  the 
IDEFO  activity  modeling  used  to  develop  the 
foundation  for  developing  a  process  for  business 
process  improvement.  The  workshop  team  will 
build  a  high  level  IDEFO  model  to  reflect  the 
processes  that  improve  business  processes.  The 
workshop  team  will  use  the  model  as  the 
foundation  for  developing  a  preliminary  Process 
Improvement  Process  (PIP)  Plan.  The  model  and 
initial  performance  metrics  will  be  documented  in 
the  Business  Process  Improvement  Plan  that  is 
the  primary  deliverable  for  the  workshop.  The 
report  will  present  recommendations  for  specific 
follow-on  projects  and  implementation  actions. 
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Figure  2:  Description  ofCIM  Business  Process  Improvement  Scoping  Workshop 

Details  of  the  workshop  implementation  for 
this  engagement  are  provided  in  the  Executive 
Summary. 


Group  Accumulation  Technique 

In  the  group  accumulation  process,  the 
facilitator  begins  by  reviewing  the  objectives  of 
the  session.  A  session  objective  might  be  to 
develop  a  program  mission  statement  (i.e., 
articulate  program  goals).  It  might  be  to 
identify  the  critical  success  factors  required  for 
attacking  identified  problems.  It  might  be  to 
identify  considerations  to  be  incorporated  in 
the  definition  of  an  ICOM. 

In  the  example  of  an  order  processing 
situation,  the  facilitator  might  start  the  group 
accumulation  by  asking,  "Management  and 
staff  have  complained  that  there  is  too  much 
paperwork  involved  in  serving  our  customers. 
Also,  order  clerks  can't  get  the  information 
they  need  fast  enough  to  respond  efficiently  to 
customers.  Our  objective  for  this  session  is  to 
identify  the  critical  success  factors  that  are 
required  to  solve  these  problem." 

At  this  point,  each  participant  is  asked  to 
record  several  ideas  on  a  piece  of  paper. 
Normally  five  to  ten  minutes  is  allocated  for 
the  completion  of  this  step. 

Participants  are  told  that  the  papers  will  not  be 
collected,  since  they  are  merely  for  recording 
ideas  that  may  be  contributed  later  in  the 
meeting.  Participants  may  or  may  not  share  all 
of  their  recorded  ideas  with  the  group. 
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The  facilitator  asks  participants  to  follow  these 
instructions: 

•  Refrain  from  talking  to  one  another 
about  the  ideas  they  are  recording 

•  Write  down  anything  that  comes  to 
mind,  and  write  it  as  clearly  as 
possible. 

When  participants  are  through  recording  their 
ideas,  the  facilitator  begins  the  group 
accumulation,  which  involves  the  steps  that 
follow. 

1.  Each  participant,  in  turn,  submits 
one  idea  to  the  group. 

2.  The  facilitator  records  each 
submitted  idea  on  a  flipchart,  but 
s/he  does  not  repeat  an  idea  that 
has  already  been  mentioned. 

Complicated  ideas  should  be 
subdivided  into  simpler  ideas. 

Ideas  should  be  limited  to  one  or 
two  lines  on  the  flipchart.  As 
flipchart  pages  become  full,  they 
should  be  hung  on  the  wall  so  they 
are  visible  to  the  entire  group. 

3.  As  each  idea  is  listed  on  the 
flipchart,  the  facilitator  makes  sure 
that  everyone  understands  the  item 
listed  (participants  can  ask  for 
clarification  at  any  point  in  the 
process).  The  submitter  is  asked  to 
clarify  any  questions  about  a 
specific  idea. 
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4.  The  facilitator  then  asks  if  anyone 
objects  to  an  idea  or  challenges  it  as 
inappropriate. 

5.  If  an  idea  is  challenged,  the  scribe 
places  brackets  around  the  item  on 
the  flipchart.  The  challenge  is  not 
discussed  by  the  group  at  this  time. 

6.  When  everyone  in  the  group  has 
contributed  one  idea,  the  facilitator 
begins  the  process  again  by  asking 
each  participant  for  an  additional 
idea.  If  a  participant  does  not  wish 
to  make  a  contribution,  s/he  simply 
says,  "Pass." 

7.  Each  member  of  the  group  must 
pass  in  turn.  When  the  entire  group 
passes  three  times  in  succession,  the 
group  accumulation  process  is 
completed. 

8.  If  any  member  of  the  group  makes  a 
new  contribution  before  three 
complete  group  passes,  the  three 
passes  rule  goes  into  effect  once 
again.  This  rule  ensures  that  group 
members  can  contribute  as  many 
ideas  as  they  wish. 

Generally,  the  process  requires  participants  to 
make  efficient  use  of  the  allotted  time.  If  the 
facilitator  notices  that  time  is  running  short, 
participants  should  be  encouraged  to  finish 
submitting  ideas.  Throughout  the  group 
accumulation  process,  it  is  the  facilitator's  role 
to  see  that  a  steady  pace  is  maintained. 
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After  all  ideas  have  been  recorded  and 
understood  by  the  team,  the  next  step  is  to 
clear  the  challenges  by  removing  the  brackets 
from  challenged  ideas.  This  procedure  will 
indicate  which  ideas  fit  into  the  pattern  and 
which  are  irrelevant.  Ideas  should  be 
synthesized  and  collapsed  into  categories. 

Then,  the  person  who  challenges  an  idea  is 
asked  to  explain  to  the  group  why  s/he  objects 
to  the  item.  After  this  explanation  is  given,  the 
person  who  contributed  the  idea  is  asked  if  it 
should  be  deleted  or  saved.  If  the  challenger 
can't  express  persuasive  reasons  why  the  idea 
should  be  deleted,  and  the  submitter  can't 
decide  what  to  do,  then  the  fate  of  the  idea  is 
decided  by  a  majority  vote  of  the  group. 

After  all  bracketed  items  have  been  resolved, 
the  data  discovery  process  has  been  completed, 
and  the  session  is  over.  The  result  is  a  list  of 
ideas  that  need  to  be  explored  more 
thoroughly  in  other  information-gathering  or 
modeling  activities. 

The  discarded  ideas  should  be  noted  and  kept 
as  a  separate  list  for  possible  future  use.  An 
idea  that  seems  far-fetched  now  may  be  useful 
in  the  future. 


Objectives  and  Critical  Success  Factors 

Objectives 

The  REAP  Team  used  the  Group  Accumulation 
Technique  to  establish  the  objectives  for  the 
process  model  resulting  from  the  Scoping 
Workshop.  Throughout  the  five  days,  the  team 
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revisited  these  objectives  to  ensure  that  the 
model  adequately  addressed  these  concerns. 

Objectives  are  defined  as  specific  targets  which 
are  intended  to  be  reached  at  a  given  point  in 
time.  An  objective  is  an  operational 
transformation  of  one  or  more  goals. 

Objectives  are  measurable,  quantifiable, 
controllable,  and  transformable.  Objectives 
must  also  be  congruent  with  other  objectives. 

The  objectives  are  presented  in  no  particular 
order. 

1.  The  PIP  should  be  as  concise  as 
possible 

2.  The  PIP  will  focus  on  its 
implementation,  so  that  financial  or 
functional  managers  know  what  to 
do  next. 

3.  The  PIP  will  be  described  in  a 
manner  similar  to  the  way 
functional  managers  talk  about  their 
work. 

4.  The  PIP  will  be  described  such  that 
implementers  will  see  their  own 
process  when  implementing  the  PIP 

5.  The  PIP  will  be  described  clearly,  so 
it  is  as  easily  understandable  as 
possible. 


Critical  Success  Factors 

The  REAP  team  used  the  set  of  group- 
accumulated  objectives  as  candidate  for  critical 
success  factors. 
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Critical  success  factors  are  defined  as  the 
limited  number  of  areas  in  which  satisfactory 
results  will  ensure  successful  performance  for 
the  functional  managers.  Critical  success 
factors  are  the  few  key  areas  in  which  “things 
must  go  right"  for  PIP  to  succeed  and  for  the 
managers'  own  objectives  to  be  attained.  Since 
they  are  a  subset  of  PIP  objectives,  the  project 
critical  success  factors  are  measurable, 
quantifiable,  controllable,  and  transformable. 

The  REAP  Team  achieved  consensus  deriving 
the  following  critical  success  factors  from  the 
set  of  objectives. 

1.  The  PIP  must  be  applicable  to 
manufacturing  and  service 
operations. 

2.  The  PIP  will  be  presented  as  a 
"cookbook"  guide  with  an 
explanation  of  the  underlying 
theory 

3.  The  PIP  will  make  process 
improvement  clear  and  accessible  to 
functional  managers 

4.  The  PIP  will  help  to  identify 
meaningless  activities 

5.  The  PIP  will  be  operational 

6.  The  PIP  will  be  detailed  enough  to 
be  implement  able 

7.  The  PIP  will  be  easily  modifiable 


46 


PIP  Process  Model 


8.  The  PIP  will  either  identify 
improvement  methods  or  a  method 
for  identifying  improvement 
methods. 

9.  The  PIP  will  be  generic  enough  to  be 
applicable  across  different  levels  of 
management 

10.  The  PIP  will  help  identify  value- 
added  activities 

11.  The  deliverable  will  completely 
describe  the  PIP 

12.  The  PIP  will  provide  functional 
managers  with  a  way  to  envision 
alternatives  to  the  current  process 
and  will  make  the  paradigm  shift 
obvious 

13.  The  existing  process  must  be 
accurately  defined  in  PIP. 


Process  Model  Diagrams 


The  next  few  pages  feature  IDEFO  (process) 
model  diagrams  of  the  process  to  create  the 
Process  for  Process  Redesign.  The  node  tree 
shows  all  activities  within  the  scope  of  "Create 
a  Process  for  Process  Redesign."  The  Context 
Diagram  depicts  high  level  inputs,  controls, 
outputs,  and  mechanisms  for  this  process.  The 
AO  Decomposition  Diagram  shows  how  high- 
level  activities  in  "Create  a  Process  for  Process 
Redesign"  relate  to  one  another  and  produce 
and  exchange  information  about  process 
redesign  in  the  DOD  environment. 
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For  a  primer  on  reading  IDEFO  models,  please 
refer  to  the  appendix  “Process  Model  Reader's 
Guide"  immediately  following  this  section. 
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The  PIP  must  be 
applicable  to 
manufacturing  and 
service  operations. 

The  PIP  should  be  as 
concise  as  possible 

The  PIP  will  be 
presented  as  a 
"cookbook"  guide  with 
an  explanation  of  the 
underlying  theory 

The  PIP  will  make 
process  improvement 
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The  PIP  will  focus  on 
its  implementation,  so 
that  financial  or 
functional  managers 
know  what  to  do  next. 

The  PIP  will  either 
identify  improvement 
methods  or  a  method 
for  identifying 
improvement  methods. 

The  PIP  will  be  generic 
enough  to  be 
applicable  across 
different  levels  of 
management 

The  PIP  will  be 
described  in  a  manner 
similar  to  the  way 
functional  managers 
talk  about  their  work. 

The  PIP  will  be 
described  such  that 
implemented  will  see 
their  own  process  when 
implementing  the  PIP 

The  PIP  will  help 
identify  value-added 
activities 
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IDEFO  Model  Glossary 


The  definitions  for  the  activities  and  ICOMs 
appearing  in  the  PIP  model  appear  below. 

This  glossary  is  an  integral  part  of  the  activity 
model  and  workshop  deliverable.  These 
definitions  should  be  read  closely,  for  they  give 
greater  depth  and  meaning  to  the  diagrams 
just  presented. 


Activities 


AO  Create  a  Process  for  Process  Redesign 
This  process  uses  REAP's  knowledge, 
experience,  and  other  necessary  resources 
to  develop  process  redesign 
implementation  guidance  for  DOD 
functional  managers.  It  also  results  in 
enhanced  knowledge  of  process  redesign, 
DOD  resource  policies,  assumptions 
about  DOD  functional  managers,  and  the 
limits  of  REAP's  knowledge  base  pose 
constraints  on  this  activity. 
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Al  Describe  How  to  Marshall  Resources 
This  process  uses  REAP's  knowledge, 
experience,  and  other  necessary  resources 
to  develop  a  framework  for  assembling 
and  organizing  the  resources  necessary  to 
initiate  and  accomplish  process 
reengineering.  These  resources  include, 
but  are  not  limited  to,  people,  funds, 
seminars,  technology,  and  ideas. 

A  functional  manager  responsible  for 
bringing  about  process  redesign  will  be 
unable  to  model  or  portray  existing  AS-IS 
processes  if  s/he  does  not  understand 
how  to  gather  the  resources  to  undertake 
the  project.  The  extent  of  this  knowledge 
will  affect  the  amount  of  resources  that 
can  be  brought  to  bear  in  the  effort  to 
understand  process  change. 

These  resources  include,  but  are  not 
limited  to,  people,  funds,  seminars, 
technology,  and  ideas.  The  mechanisms 
to  assist  in  this  process  are  REAP  and 
techniques  for  marshalling  resources. 

All  Define  Process  Improvement  Resources 
This  process  describes  how  to  determine 
what  resources  are  available  to 
accomplish  process  redesign. 

A12  Describe  How  to  Select  Process 
Improvement  Resources 
This  process  describes  how  to  choose 
those  resources  appropriate  for  the  given 
redesign  process. 
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A13  Describe  How  to  Compare  What's 
Needed  to  Existing  Resources 
This  process  describes  how  to  evaluate 
what  resources  are  lacking,  if  any.  For 
example,  inventories  of  skills,  knowledge, 
and  experience  (both  needed  and 
available)  must  be  taken  and  compared  to 
identify  deficiencies.  Specific  tools  for 
evaluating  these  resources  and  converting 
one  resource  to  another  must  be 
addressed. 

A14  Describe  How  to  Acquire  Resources 
This  process  describes  how  to  obtain  or 
appropriate  resources  which  are  lacking. 

A15  Describe  How  to  Apply  Resources 

This  process  describes  how  to  put  to  use 
the  resources  which  are  necessary  for 
process  redesign. 

A16  Describe  How  to  Measure  Resource 
Utilization 

This  process  describes  how  to  evaluate 
resources  for  bringing  about  the  desired 
process  redesign. 
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A2  Describe  How  to  Create  an  Environment 
for  Discontinuous  Thinking 
A  functional  manager  responsible  for 
bringing  about  process  redesign  may  not 
be  able  to  execute  the  process  if  he  or  she 
cannot  assemble  a  team  with  the  requisite 
group  diversity,  frame  of  mind  and  social 
skills  to  deal  with  redesign  issues  with  an 
open  mind  and  with  a  commitment  to 
action.  This  process  uses  REAP's 
knowledge  and  experience  of  encouraging 
creative  thinking  to  explain  to  a  functional 
manager  how  to  overcome  that  deficiency 
through  training  or  facilitation  and  the 
use  of  technology. 

A21  Describe  How  to  Avoid  a  Threatening, 
Hostile  Environment 
This  process  explains  both  how  to  initiate 
and  sustain  an  environment  that 
facilitates  the  open  exchange  of  ideas. 

A22  Describe  How  to  Expand  Viewpoint 
This  process  explains  how  to  facilitate  the 
understanding  and  adoption  of  new 
perspectives  by  those  individuals 
participating  in  the  process  improvement 
process. 
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A23  Describe  How  to  Encourage  Creative 
Thinking 

This  process  explains  how  to  facilitate 
innovative  solutions  among  the 
individuals  participating  in  the  process 
improvement  process.  One  technique  for 
facilitating  the  innovative  solutions  is  to 
first  define  the  complete  redesign  team, 
then  include  an  individual  who  is  a 
supplier  to  the  process  and  an  individual 
who  is  a  customer  of  the  process. 

A24  Describe  How  to  Promote  Involvement 
This  process  explains  how  to  engender 
active  participation  in  the  individuals 
participating  in  the  process  improvement 
process. 

A25  Describe  How  to  Promote  Cross 
Functional  Thinking 
This  process  explains  how  to  facilitate 
positive  interaction  across  areas  of 
responsibility,  e.g.,  including  extending 
process  analysis  to  process  interfaces. 

A3  Describe  How  to  Understand  AS-IS 
Processes 

This  process  uses  REAP's  knowledge  and 
experience  of  portraying  an  existing  work 
process  using  methods  and  processes  to 
render  them  understandable  and 
accessible  by  functional  managers 
contemplating  the  redesign  of  their 
business  operations. 
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A31  Describe  How  to  Define  a  Process 

This  process  describes  how  to  model  and 
portray  an  activity  accurately  as  it  exists 
now.  This  process  includes  the  work  of 
measuring  the  value  added  by  activities 
and  identifying  deficiencies  in  a  process. 

A32  Describe  How  to  Define  Process 
Interfaces 

This  process  describes  how  to  define  the 
interfaces  between  the  activities  that  are 
being  modeled  and  portrayed  and  those 
tangential,  peripheral  activities  with 
which  the  modeled  activities  exchange 
inputs,  constraints,  outputs  or 
mechanisms.  This  process  includes  an 
examination  of  relationships  between 
activities  that  are  gathered  under  activity 
context  descriptions  at  a  higher  level  of 
abstraction  during  a  modeling  project. 

A33  Describe  How  to  Define  Data  Rules 

This  process  describes  how  to  define  rules 
for  data  meaning  and  usage  in  the 
databases  that  support  existing  activities 
that  are  being  portrayed  and  modeled. 

A34  Describe  How  to  Define  Data  Standards 
This  process  describes  how  to  define 
standards  for  data  elements,  including 
storage,  format,  and  media. 
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A4  Describe  How  to  Evaluate  a  Process 
This  process  uses  REAP's  knowledge  and 
experience  to  provide  an  explanation  of 
means  by  which  a  process  can  be 
measured  and  judged.  The  extent  of  this 
comprehension  will  affect  the  level  of 
understanding  of  the  selection  of  criteria 
and  methods  employed  in  business 
process  evaluation. 

A41  Describe  How  to  Select  a  Process  to 
Improve 

This  process  provides  a  description  of 
procedures  involved  in  discerning  which 
processes  will  have  a  positive  impact  if 
improved. 

A42  Describe  How  to  Measure  Process 
Performance 

This  process  provides  a  description  of  the 
methods  and  instruments  used  to 
measure  various  process  efficiencies,  such 
as  activity  based  costing,  quality  function 
deployment,  benchmarking,  and  activity 
based  analysis. 

A43  Describe  How  to  Pick  a  Measure 

This  process  describes  the  various  metrics 
and  why  they  are  used  to  assess 
corresponding  processes. 
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A5  Describe  How  to  Implement  Change 
This  process  uses  the  REAP  experience 
base,  its  understanding  of  change  doctrine 
and  long  range  DOD  strategy  to  describe 
to  functional  DOD  managers  of  all  levels 
how  to  implement  change.  The  metrics 
developed  from  this  process  are  used  to 
improve  REAP's  process  for  improving 
the  DOD  Process  Improvement  Process 
(PIP). 

A51  Describe  How  to  Conduct  Change 

This  process  uses  REAP's  understanding 
of  change  disciplines  and  the  DOD 
environment  to  produce  a  guide  for 
conducting  or  planning  a  change.  It 
addresses  the  risks,  timing  and  resource 
requirements,  and  benefits  associated 
with  a  particular  strategy  and  helps  a 
manager  select  a  method  with  acceptable 
risk  characteristics. 

A52  Describe  How  to  Select  Improvement 
Method 

This  process  uses  REAP's  understanding 
of  improvement  disciplines  and  the  DOD 
environment  to  produce  a  guide  for 
selecting  a  method  and  improving  a 
process.  It  helps  the  manager  evaluate 
characteristics  of  the  process  change  and 
the  environment  surrounding  the  process. 
This  process  also  selects  an  appropriate 
method  for  implementing  the  change. 
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A53  Describe  How  to  Simulate  Future 
Performance 

This  process  uses  REAP's  understanding 
of  enterprise  modeling  and  simulation 
disciplines  to  produce  a  guide  for  DOD 
managers  wishing  to  simulate  the  effects 
of  changes  to  processes  and  how  those 
changes  affect  an  organization,  the 
changed  processes,  and  other  processes  in 
an  organization. 

A54  Describe  How  to  Conduct  Change 

This  process  uses  REAP's  understanding 
of  change  methods  to  produce  a  guide  for 
DOD  managers  planning  or  conducting  a 
change  to  a  process.  It  includes 
organizational,  personnel,  tasking, 
information,  and  resourcing  guidelines 
for  particular  change  characteristics. 

A55  Describe  How  to  Measure  Change 
Impact 

This  process  uses  REAP's  understanding 
of  change  methods  to  produce  a  guide  for 
DOD  managers  planning  to  measure  the 
effects  of  a  process  change.  It  includes 
candidate  measurable  characteristics  for 
process  change  and  provides  mechanisms 
for  measurements.  It  also  includes 
information  about  when  and  where  to 
take  the  measurements,  who  should  take 
the  measurements,  and  what  to  do  with 
the  measurements.  It  includes 
information  on  testing  and  validating 
measurements  and  methods  to  improve 
the  measurement  process. 
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ICOMs 

Assumptions  About  Ends  Users 

Assumptions  include  such  facts  as  a  user's 
level  in  organization,  education, 
bureaucratic  experience,  capacity,  length 
of  tenure,  organizational  environment, 
and  ability  to  think  discontinuously. 

Consultants 

Specialists  in  the  field  of  process 
evaluation  hired  to  transfer  their  expertise 
on  business  process  evaluation. 

DOD  Resource  Policies 

The  statutes,  regulations,  procedures, 
customs,  and  policies  governing 
appropriation  and  allocation  of  resources. 
This  includes,  but  is  not  limited  to,  public 
law,  the  DOD  budget  process.  Federal 
Acquisition  Regulation  (FAR),  and 
Managing  to  Payroll  (MTP)  procedures. 

Enhanced  Knowledge 

The  internal  body  of  knowledge  of  an 
environment  which  has  expanded  as  a 
result  of  completing  a  process  within  PIP. 
This  heightened  awareness  serves  to 
influence  all  other  activities. 

Enhanced  Knowledge  of  Discontinuous 
Thinking  Environments 
This  knowledge  is  expanded  as  a  result  of 
completing  the  process  of  describing  how 
to  create  an  environment  for 
discontinuous  thinking.  This  heightened 
awareness  serves  to  influence  all  other 
activities. 
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Enhanced  Knowledge  of  Implementing 
Changes 

This  knowledge  is  expanded  as  a  result  of 
completing  the  process  of  describing  how 
to  implement  changes.  This  heightened 
awareness  serves  to  influence  all  other 
activities. 

Enhanced  Knowledge  of  Marshaling 
Resources 

This  knowledge  is  expanded  as  a  result  of 
completing  the  process  of  describing  how 
to  marshall  resources.  This  heightened 
awareness  serves  to  influence  all  other 
activities. 

Enhanced  Knowledge  of  Process  Evaluation 
This  knowledge  is  expanded  as  a  result  of 
completing  the  process  of  describing  how 
to  evaluate  processes.  This  heightened 
awareness  serves  to  influence  all  other 
activities. 

Enhanced  Knowledge  of  Understanding  AS- 
IS  Processes 

This  knowledge  is  expanded  as  a  result  of 
completing  the  process  of  describing  how 
to  understand  AS-IS  processes.  This 
heightened  awareness  serves  to  influence 
all  other  activities. 

Experience 

REAP's  active  participation  in  events  and 
activities  that  have  lead  to  the  creation  of 
environments  that  facilitate  discontinuous 
thinking,  including  practical  knowledge 
based  on  personal  involvement  and 
observation,  which  is  inherently  biased. 
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Experience  in  Process  Evaluation 
Memories  and  biases  concerning 
methodology,  tools,  and  techniques  of 
business  process  evaluation  based  on 
previous  involvement  with  process 
evaluation  projects. 

Experience  of  Implementing  Changes 
Memories  and  biases  concerning 
methodology,  tools,  and  techniques  of 
business  process  evaluation  based  on 
previous  involvement  with  change 
implementation. 

Experience  with  Discontinuous  Thinking 
Memories  and  biases  concerning 
methodology,  tools,  and  techniques  of 
business  process  evaluation  based  on 
previous  involvement  with  methods  to 
promote  discontinuous  thinking. 

Experience  with  Marshaling  Resources 
Memories  and  biases  concerning 
methodology,  tools,  and  techniques  of 
business  process  evaluation  based  on 
previous  involvement  with  marshalling 
resources. 

Experience  with  Understanding  Processes 
Experiences,  anecdotes,  insights, 
judgments,  biases  and  lore  about  ways  to 
understand  and  model  existing  systems 
that  exists  in  the  minds  of  practicing 
managers,  facilitators,  consultants,  subject 
matter  experts  and  others  who  constitute 
a  functional  redesign  team  or  are  engaged 
to  support  one. 
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Facilitators 

CIM  assumes  that  functional  managers 
facing  process  redesign  have  no 
background  in  its  methods,  or  techniques. 
To  start  a  redesign  project  and  shepherd  it 
through  to  completion  requires  the  help  of 
people  who  are  skilled  and  experienced  in 
process  redesign.  They  are  the  redesign 
process  facilitators.  They  may  be  found 
within  CIM,  DOD  or  in  private  consulting 
firms. 

Facilities 

Physical  sites  include  offices  and 
conference  rooms  equipped  with 
presentation  media,  desktop  publishing 
equipment,  and  analytical  tools. 

How  to  Create  a  Change  Environment 

This  is  a  set  of  ideas,  tools,  and  techniques 
that  explain  to  those  involved  in  process 
redesign  the  necessary  and  possibly 
sufficient  conditions  for  an  innovation  to 
occur.  This  set  of  ideas  encourages 
commitment  to  action  by  functional 
managers. 

How  to  Evaluate  a  Process  Change  Candidate 
A  description  of  the  principles,  methods, 
tools,  and  techniques  used  to  measure  and 
judge  business  processes  and  an 
understanding  of  when  and  how  to  use 
them. 
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How  to  Implement  Change 

A  set  of  documents  describing  the 
implementation  of  process  improvement 
within  the  DOD  environment.  Included 
are  case  studies,  charts,  tables,  theories, 
practical  application  examples, 
description  of  risks,  critical  success 
factors,  reference  models,  methods, 
training  and  education  requirements,  and 
best  practices. 

How  to  Marshall  Resources 

The  description  of  the  ideas,  tools,  and 
techniques  that  explain  to  the  manager  of 
the  process  redesign  how  to  acquire  the 
necessary  and  sufficient  tangible  and 
intangible  sources  of  support  for  the 
purpose  of  redesigning  a  process. 

How  to  Understand  AS-IS  Process 

A  document  that  describes  the  methods 
and  techniques  for  modeling  existing 
business  activities. 

How  to  Understand  Existing  Processes 

A  description  of  the  principles,  methods, 
and  tools  used  to  understand  business 
processes. 

IDEF  Techniques 

IDEF  (ICAM  DEFinition  language)  is  a 
family  of  modeling  techniques  that  are 
easily  understood  by  managers  and 
developers  of  information  systems.  IDEFO 
(IDEF  zero)  models  processes. 
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Knowledge 

REAP's  awareness  and  comprehension  of 
techniques,  processes,  and  activities  that 
facilitate  the  creation  of  environments 
conducive  to  discontinuous  thinking. 

This  awareness  is  learned  through 
training  and  intellectual  investigation 
rather  than  practical  experience. 

Knowledge  of  Discontinuous  Thinking 
Prior  understanding  of  the  methods 
available  to  expand  the  viewpoints  of  a 
redesign  team. 

Knowledge  of  Existing  Resources 

The  current  awareness  of  resources 
available  to  those  involved  in  the  process 
improvement  process  (PIP). 

Knowledge  of  Marshaling  Resources 
Practical  knowledge  of  marshaling 
resources  to  support  an  event  or  process. 

Knowledge  of  Process  Evaluation 
Any  prior  understanding  of  the 
principles,  methods,  and  practices  used  to 
measure  and  judge  business  processes 
gained  through  the  study  of  business 
process  evaluation. 

Knowledge  of  Understanding  Processes 
Written,  documented  lore  about  ways  to 
understand  and  model  existing  systems 
that  exists  in  books,  reports,  academic 
literature,  conference  papers  and  business 
and  trade  periodicals. 
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Limits  of  Knowledge 

The  parameters  of  REAPs  knowledge 
base  that  constrains  the  development  of 
PIP. 

Metrics 

Units,  standards  and  criteria  involved  in 
the  process  of  measurement.  In  PIP, 
measurement  of  both  qualitative  and 
quantitative  aspects  of  a  process  are 
included. 

Modeling  Technology 

The  primary  technology  employed  in 
describing  existing  business  processes  is 
the  software  that  models  the  IDEF 
techniques. 

REAP 

Those  individuals,  organizations,  and 
conventions  facilitating  the  process 
improvement  process.  Up  to  the 
publication  date  of  this  model,  REAP 
(Redesign  Experts  and  Practices) 
consisted  of  the  accumulated  knowledge, 
bias,  energy,  insight,  and  analytical  skills 
of  a  diverse  group  including  three  NPS 
graduate  students,  three  NPS  faculty 
members,  an  NPS  dean,  and  two  D. 
Appleton  Company  facilitators. 

REAP  Database 

The  REAP  database  contains  the 
following  resources  to  assist  functional 
management  redesign  teams: 

1.  Lists  of  names  and  contact 
points  for  experts  and 
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facilitators  in  activity  redesign 
methods  and  techniques. 

2.  Lists  and  brief  descriptions  of 

methods  and  techniques  for 
modeling,  portraying  and 
analyzing  existing  business 
processes. 

3.  Lists  of  activities  in  DOD  and 

firms  in  the  private  sector  that 
have  already  experienced 
process  redesign  and  offer 
contact  points  willing  to  share 
their  experience  with  you. 

4.  Lists  of  business  process  metrics, 

i.e.,  what  measures  are  best 
employed  to  evaluate  certain 
processes. 

Techniques  and  Methods 

Examples  of  techniques  and  methods 
include  a  set  of  exercises,  readings, 
lectures,  audio-visual  media  and  other 
devices  that  are  available  to  the  team  and 
its  facilitators  to  reach  a  commitment  to 
action  by  the  team  members. 

Techniques  for  Implementing  Change 
Methods,  procedures  and  conventions 
used  to  change  business  processes. 

Techniques  for  Marshaling  Resources 

Generally  accepted  DOD  procedures  and 
practices  for  acquiring  resources. 
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Techniques  for  Understanding  Processes 

Methods  for  bringing  about  discontinuous 
thinking  among  the  members  of  a 
functional  redesign  team  in  order  to 
examine  and  describe  their  activities  in  a 
useful,  accurate  portrayal  unencumbered 
by  suboptimal  biases  or  departmental 
politics. 

Techniques  of  Discontinuous  Thinking 
Techniques  for  use  with  individuals 
involved  in  process  redesign,  some 
examples  are 

•  Framing  and  reframing  exercises 

•  Use  of  creative  thinking  exercises 

•  Developing  multiple  interpretation 
exercises 

•  Escaping  from  dominant  ideas 
exercises 

•  A  checklist  on  how  to  kill  creativity 

•  Readings  and  discussion  of 
groupthink 

•  Readings  and  discussion  of 

unconscious  aspects  of 

organizations 

•  Readings  and  discussion  of  how 

organizations  can  obstruct 

learning 

•  Readings  and  discussion  of  conflicting 

messages  sent  by 

organizations. 

Time 

Deadlines  on  the  execution  of  each 
process  in  PIP. 
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Guide 


Overview 


The  purpose  of  this  paper  is  to  provide 
guidelines  for  reading  and  understanding 
IDEFO  Activity  Models.  It  is  not  intended  to  be 
an  instructional  manual  in  the  techniques  of 
building  such  models.  Rather,  it  is  intended  to 
specify  the  basic  components  of  an  Activity 
Model  and  their  interpretation. 

The  use  of  IDEFO  is  supported  by  software  that 
maintains,  analyzes,  and  cross-references 
models.  D.  Appleton  Company  has  developed 
a  computer  processable  language,  called 
Activity  Modeling  Language  (AML),  which  can 
be  used  to  define  IDEFO  models  for  computer 
processing. 

An  IDEFO  Activity  Model  may  be  defined  as  a 
graphic  portrayal  of  the  processes  within  an 
organization.  That  is,  the  model  depicts  the 
specific  steps,  operations,  and  data  elements 
that  are  needed  to  perform  an  activity.  It  is 
important  to  understand  that  the  model  does 
not  represent  a  "time-flow;"  that  is,  it  does  not 
define  a  sequential  time-constrained  set  of 
tasks,  but  rather  the  logical  interdependency  of 
various  types  of  activities. 


Definition  of  Activity 


An  activity  is  a  named  process,  function,  or 
task  that  has  one  or  more  occurrences  over 
time  and  produces  recognizable  results. 
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Uses  of  the  Activity  Model 


One  of  the  most  important  uses  of  the  model  is 
to  define  the  scope  of  a  project.  It  may  be 
developed  from  the  viewpoint  of  the  functional 
group  performing  the  activity  -  what  the 
system  will  do,  from  the  viewpoint  of  the 
designer  -  how  the  system  will  be  built,  or  from 
the  viewpoint  of  the  operator  -  how  the  system 
will  be  maintained.  The  model  may  represent 
as  broad  or  as  narrow  a  viewpoint  as  is 
required  and  may  be  refined  further  and 
further  into  more  detail.  If  several  viewpoints 
are  needed,  separate  models  are  developed  for 
each  one. 

Another  use  of  the  Activity  Model  is  for  "data 
discovery  and  validation"  since  the  model 
shows  the  relationship  between  an  activity  and 
the  information  that  is  used  to  perform  the 
activity.  Data  elements  can  be  extracted  from 
the  model  and  can  be  used  to  specify 
transactions  which  may,  in  turn,  eventually  be 
used  to  automate  the  process.  After  these  data 
elements  are  documented  in  a  data  model,  the 
activity  model  can  be  referenced  for  validation 
purposes. 

Documentation  of  the  "as-is”  environment  is 
another  important  use  of  the  Activity  Model 
because  the  model  is  similar  to  a  "snapshot"  of 
an  organization's  activities  at  a  particular 
moment  in  time.  It  can,  therefore,  be  useful  for 
documenting  how  an  organization  really 
functions.  The  model  can  be  used  to  describe 
operations,  processes  and  procedures, 
interactions,  interfaces,  directions,  etc.,  in  the 
existing  environment.  The  Activity  Model, 
which  reflects  the  "as-is"  environment,  is  also 
useful  in  problem  identification. 

The  "to-be"  environment  can  also  be 
documented  through  development  of  an 
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Activity  Model,  showing  proposed  changes  to 
the  processes,  procedures,  mechanisms,  etc. 

The  remainder  of  this  paper  will  address 
Activity  Models  primarily  as  a  means  of  data 
discovery  and  validation,  which  can  form  the 
basis  for  development  of  an  IDEF1X  semantic 
data  model. 


Components  of  an  Activity  Model 

The  result  of  applying  the  IDEFO  activity 
modeling  technique  is  an  understanding  of  the 
activities  in  the  environment  and  their  use  of 
information  or  materials. 

•  These  are  typically  represented  by 
three  different  types  of  activity 
diagrams: 

Node  trees,  which  graphically 
portray  activities  in  a  hierarchical 
format. 

Context  diagrams,  which 
illustrate  individual  activities  and 
their  inputs,  controls,  outputs, 
and  mechanisms,  in  terms  of 
either  information  or  materials. 

Decomposition  diagrams,  which 
represent  a  refined  definition  of 
an  activity  by  showing  its  lower- 
level  activities  and  the 
interrelationships  of  inputs, 
controls,  outputs,  and 
mechanisms. 

•  An  Activity  Model  also  includes  a 
glossary  that  defines  the  terms,  or 
labels,  used  on  the  diagrams. 
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•  The  model  also  includes 

explanatory  text  in  paragraph  form 
that  describes  an  entire  diagram, 
including  what  goes  on  in  each 
activity  and  how  activities  in  the 
diagram  interact. 


Activities:  A  Building  Block  of  the  Activity  Model 

In  an  IDEFO  modeling  diagram,  an  activity  is 
represented  graphically  by  a  rectangular  box. 
Each  activity  box  is  labeled  using  an  active 
verb  or  verb  phrase. 

Any  complex  activity  can  be  broken  down  into 
smaller,  more  detailed  activities.  The  process 
of  breaking  down  an  activity  into  subactivities 
is  called  decomposition.  Activity  modeling 
uses  functional  decomposition's  as  the 
foundations  for  model  refinement  and 
validation. 

ICOMs:  Another  Building  Block 

Often  information  or  materials  produced  in 
one  activity  are  used  in  others.  These  ICOMs 
or  "activity  relationships"  are  represented  by 
arrows  interconnecting  the  activity  boxes  and 
are  named  with  a  noun  or  noun  phrase. 

The  term  "ICOM"  is  the  acronym  of  the  four 
possible  roles  relative  to  an  activity: 

•  Input  -  data  or  material  used  to 
produce  the  output  of  an  activity 

•  Control  -  data  that  constrain  an 
activity.  Controls  regulate  the 
transformation  of  inputs  into 
outputs 

•  Output  -  data  or  materials  produced 
by  or  resulting  from  the  activity 
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Input 


•  Mechanism  -  usually  people, 

machines,  or  existing  systems  that 
perform  or  provide  energy  to  the 
activity 

j 

The  particular  role  of  an  ICOM  is  identified  bv 
the  position  of  its  arrow  in  relation  to  the 
activity  box,  proceeding  clockwise  around  the 
four  sides  of  the  activity  box.  Refer  to  the 
representation  of  an  activity  illustrated  in 
Figure  3. 


Control 


_ L 

Activity 


4 


►  Output 


Mechanism 


Figure  3.  IDEFO  Graphical  Syntax 

Activity  Node  Trees 


At  times,  it  is  useful  to  identify  a  number  of 
activities  of  interest  and  their  potential 
decomposition  relationships  before 
diagramming  them  and  identifying  their 
associated  ICOMs.  In  these  cases,  activities  can 
be  displayed  on  a  single  structured  diagram  for 
easy  reference,  using  a  graphic  convention  that 
resembles  a  tree.  Consequently,  it  is  referred  to 
as  a  "node  tree."  A  node  tree  is  illustrated  in 
Figure  4. 

Each  node,  or  dot,  on  the  tree  represents  an 
activity.  Each  arc,  or  line,  from  one  activity  to 
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the  next  lower  level  subactivity  represents  a 
decomposition  relationship.  Node  trees  do  not 
depict  ICOMs. 

All  activities  in  a  node  tree  must  be  given  an 
activity  name  and  be  numbered.  Each 
decomposition  of  an  activity  assumes  the 
number  identity  of  the  parent  activity  and  adds 
an  additional  decimal-separated  integer 
indicating  its  relative  position  to  its  peers. 


Context  Diagram 

A  context  diagram  shows  only  one  activity  and 
its  ICOMs.  A  context  diagram  is  always 
prepared  for  the  top-most  activity  in  a  node 
tree,  but  it  can  also  be  prepared  for  any  other 
activity.  The  number  of  a  context  diagram  is 
the  same  as  that  of  the  activity  it  shows.  Its 
name  consists  of  the  phrrlse  "context  for" 
followed  by  the  name  of  the  activity.  The 
number  and  name  appear  at  the  bottom  of  the 
diagram.  Figure  5  illustrates  a  context 
diagram. 


Decomposition  Diagrams 


Each  activity  on  a  diagram  may  be  described  in 
more  detail  (i.e.,  decomposed)  on  a  separate, 
lower-level  diagram.  This  lower-level  diagram 
is  used  to  show  the  subactivities  which, 
together,  are  represented  by  the  parent  activity 
box. 

The  number  of  a  decomposition  diagram  is  the 
same  as  the  number  of  the  parent  activity, 
whose  decomposition  is  shown.  The  AO 
decomposition  diagram,  for  example,  shows 
the  decomposition  for  the  AO  activity.  The 
diagram  depicts  the  subactivities  Al,  A2,  A3, 
etc.,  which  define  the  overall  AO  activity.  A 
decomposition  diagram  is  illustrated  in  Figure 
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6.  The  A2  decomposition  diagram  would  show 
the  decomposition  for  the  A2  activity.  It  would 
illustrate  activities  A2.1.,  A2.2,  A2.3,  etc.  The 
name  of  a  decomposition  diagram  begins  with 
the  words  "Decomposition  of,"  followed  by  the 
name  of  the  parent  activity.  If  a  diagram 
replaces  a  previous  diagram  in  a  model,  it 
keeps  the  same  node  identification,  but  it  must 
be  updated  with  the  appropriate  revision 
identification. 

AO 


Design 

Electronic  and 
Electrical  Products 


Electronic  and  Design  Analyses  Electronic  and 


Validate  Generate  Analyze 

Functional  Physical  Physical 

Design  Design  Design 

Requirement 

Figure  4:  Activity  Node  Tree 
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RECOMMENDED 
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Decomposition  of  Design  Electronic  end  Electrical  Products 


Model  Glossary 


The  glossary  provides  definitions  of  the 
activities  and  ICOMs  that  appear  on  the 
Activity  Diagram.  These  are  definitions  that 
have  been  developed  and  agreed  upon  by  the 
modeling  team  during  the  process  of  building 
the  activity  model.  Developing  the  glossary 
also  provides  the  model  builders  with  a  good 
cross-check  to  ensure  that  all  activities  and 
ICOMs  are  appropriately  identified  and  clearly 
defined. 


Narrative  Text 


This  is  the  English  language  version  of  the 
pictorial  diagram  or  view.  It  is  narrative 
textual  information  that  uses  declarative 
statements  to  describe  what  is  happening  in 
each  activity  box  in  the  diagram,  including 
interaction  between  activities.  It  includes  the 
object  of  each  activity  and  a  description  of  the 
tasks  (decomposition)  that  are  performed  to 
complete  the  activity. 

Often  there  is  also  included  a  statement  that 
discusses  the  scope,  objectives,  and  viewpoint 
of  the  activity  model. 


Conclusion 


While  this  write-up  has  not  gone  into  the  more 
sophisticated  features  of  activity  models,  e.g., 
feedback  loops,  pipelines,  tunneling,  paths, 
ICOM  traceability,  and  supplemental  views,  it 
should  present  a  framework  of  understanding 
for  reading  such  models. 
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The  IDEFO  activity  modeling  technique  is  a 
simple  but  rigorous  technique  that  facilitates 
communication  about  how  an  organization 
functions  in  either  its  current  or  proposed 
future  environment.  The  diagrams  can  be 
understood  easily  by  both  business 
professionals  and  data  processing  professionals 
and  can  be  used  to  discuss  complex  processes. 

The  IDEFO  activity  modeling  technique 
provides  an  opportunity  for  involvement  and 
consensus  among  diverse  members  of  an 
organization  as  they  define  a  common  view  of 
their  environment  and  a  strategy  for 
integration. 


83 


LIST  OF  REFERENCES 


D.  Appleton  Company,  Inc.,  “Corporate  Information  Management  Process 
1992  Improvement  Methodology  for  DOD  Functional  Managers." 

Leong-Hong,  Belkis.  "CIM  Functional  Groups:  Overview  and  Status," 

1990  Presentation,  Office  of  the  Secretary  of  Defense,  1 8  June. 

REAP  Report:  “Corporate  Information  Management  Process  for  Process 
1992  Redesign  IDEF  Modeling  Findings  and  Recommendations," 

Naval  Postgraduate  School,  March. 

Schweizer,  David  D.  and  Steele,  James  P.  Ill,  “Corporate  Information 

1991  Management;  A  Case  Study,"  Naval  Postgraduate  School, 
Monterey,  California,  March. 

U.S.  Department  of  Defense.  “Defense  Management  Report  to  the  President.” 
1989  Washington,  D.  C.,  Office  of  the  Secretary  of  Defense,  July. 


84 


0 


BIBLIOGRAPHY 


Camp,  Robert  C.,  Benchmarking:  The  Search  for  Industry  Best  Practices  That 
Lead  to  Superior  Performance,  ASQC  Quality  Press,  1989. 

Hammer,  Michael,  “Re-engineering  Work:  Don’t  Automate,  Obliterate” 
Harvard  Business  Review,  July-August  1990. 

Port,  Otis,  and  John  Carey,  “Questing  for  the  Best”  Business  Week  special 
1991  bonus  issue — The  Quality  Imperative.  Feb,  1991 

Strassmann,  Paul  A.,  Business  Value  of  Computers,  Information  Economics 
Press,  1990. 

Verity,  John  and  Gary  McWilliams,  “Is  it  time  to  junk  the  way  you  use 
computers?”  Business  Weekly  July  22,  1991. 


85 


INITIAL  DISTRIBUTION  LIST 


Defense  Technical  Information  Center 
Cameron  Station 
Alexandria,  VA  22304-6145 

Library,  Code  52 

Naval  Postgraduate  School 

Monterey,  CA  93943-5002 

Dr.  William  J.  Haga,  Code  AS/HG 
Department  of  Administrative  Sciences 
Naval  Postgraduate  School 
Monterey,  CA  93943-5002 

Dr.  Kenneth  J.  Euske,  Code  AS/EU 
Department  of  Administrative  Sciences 
Naval  Postgraduate  School 
Monterey,  CA  93943-5002 

LCDR  Scott  A.  White 
HC-I  NAS  North  Island 
San  Diego,  CA  92 1 35-5 1 98 


